Reading Time: 1 minutes

インシデント管理の業務ではパッケージソフトを利用することで、スクラッチソフトと比較してソフトウェアの運用・保守コストを減少させることができます。スクラッチソフトを使っている現場で「コストを削減」と言われているのであれば、パッケージソフトが魅力的な選択になるかと思います。コスト削減のポイントになる部分が明確になれば、パッケージソフト導入の理由として説明することができるようになるでしょう。

ここではソフトウェアの運用・保守の点について、それぞれパッケージとスクラッチを利用した場合を比較することで、コスト削減のポイントが理解できるように説明していきます。

パッケージソフトの導入で運用・保守コストが低減可能な理由

インシデント管理業務にパッケージソフトを導入することで、ソフトウェアの運用・保守コストを低減できます。特にスクラッチソフトウェアを利用している場合、このコスト削減の傾向はより顕著になると思います。

パッケージソフトが低コストで運用できるポイント

パッケージソフトとスクラッチソフトを比較した時に、運用・保守コストが下げられるポイントは、主に以下の点があげられます。

  • ソフトウェアの開発に必要な人員
  • ソフトウェア運用の委託
  • バグ修正などの問題の対応
  • ソフトウェアに付帯したサポートサービスの有無 など

あたりまえのことですが、パッケージソフトは開発ベンダーから提供されています。つまり、ベンダー側に開発・保守の専任技術者がいることになります。代表的な事例として、ソフトウェアのバグ発生時の対応が考えられるでしょう。バグが発生したら、基本的に開発元に問い合わせるところまでは、パッケージソフトもスクラッチソフトも同じかと思います。

パッケージソフトの場合、ユーザーはベンダー窓口に問い合わせて、その後の対応は全てベンダー側で処理されます。

一方、スクラッチソフトの場合は、ユーザーは問い合わせ先として開発元に連絡をしますが、開発に関わっている社内の人員以外に、委託開発で対応している場合は、委託先も連絡先に含まれます。どの様な事象が発生しているのか調査から始まり、最終的に修正が完了するまでに要した社内の人員と、委託開発であればバグ修正に相応したコストが費用に反映されます。パッケージソフトはほとんど場合、買い切りか年間又は月額のライセンスによって予め価格が決まっているので、バグ修正等にかかる費用負担が発生することはありません。

また、パッケージソフトではバグ対応も含めてソフトウェアの開発について自社で開発要員を抱える必要がなく、全ての対応をベンダーに依頼できます。社内ではツールを利用する最低限の要員だけで対応できるため、ソフトウェアの専任も不要となり、コストを抑えることができます。

また、パッケージソフトにはサポートサービスが付帯しているものもあります。この点は、パッケージならではのメリットになります。

ソフトウェアに関連するコストとは

次にソフトウェアにかかる運用のコストについて、スクラッチソフトとパッケージソフトの特性を比べて、コストが変わりそうなポイントを見ていきます。

なお、以下で扱う人月費は70万円/人月として試算することといたします。

ソフトウェア運用コスト

前提になる条件として、スクラッチソフト、パッケージソフトともに運用に必要な要員を置くこととして、ソフトウェアの稼働にかかるコストに絞って説明いたします。なお、いずれの環境でも利用者数や機能規模は同程度のものとして考えていきます。

ヘルプデスク業務のソフトウェア稼働コスト比較
スクラッチソフト パッケージソフト
ソフトウェア運用 社内要員2人月程度(専任が望ましい) 社内要員0.5人月~2.0人月程度(ヘルプデスク業務との兼用も可能)
合計 140万円 35万円~140万円

ソフトウェア稼働の専任について、スクラッチでは専任を2人月、パッケージでは0.5人月~としています。運用や機能の規模を示さずに、人数だけ仮置きしたような状態ではありますが、一般的なインシデント管理ツールとして十分最低限の機能を備えていることとした条件であれば、それほど遠くはないかと思います。ポイントになるのは、運用にかかる人的コストの差異になります。

スクラッチもパッケージと同様に、ヘルプデスク業務と兼任できないわけでもありませんが、「ソフトウェアにトラブルが発生した際に、対応できる人員をすぐにアサインできるか?」といった観点から考えると、ヘルプデスク業務と役割を分けて、ソフトウェアの専任者を用意したほうが良いでしょう。

パッケージソフトではベンダー側にエンジニアがいるため、運用現場から直接問い合わせて対応することも可能です。ソフトウェアの利用に慣れてくれば、ヘルプデスク業務と兼任で対応することもできるようになるかと思います。

一方、スクラッチでは専任の担当を社内で用意できない場合は、開発ベンダー側でアサインすることになるため、社内外問わず専任の要員が必要になります。ソフトウェアの運用面でコスト高になりやすいポイントは運用のための人員で、社内で対応する場合は実費には出ない目に見えないコスト、社外の要員をアサインする場合は、保守費用等の名目で実費として費用負担が求められます。

ソフトウェア保守コスト

次にソフトウェア保守のコストを比較してみます。なお、本来はソフトウェアが稼働する環境に当たる、ハードウェアやミドルウェアの保守コストも考慮する必要がありますが、今回はソフトウェアのコストに絞って説明いたします。

パッケージソフトウェアのライセンスについては、ServiceDesk Plusの年間ライセンス(年間48.5万~)を月次按分して比較しています。

ヘルプデスク業務のソフトウェア稼働コスト比較
スクラッチソフト パッケージソフト
ライセンス費用 12.5~37.5万円/月
(ソフトウェア保守費として)
約4万円/月~(年間48.5万円~)
機能追加 必要に応じて費用発生 バージョンアップで対応
バグ修正 都度対応
(0.2人月と仮定)
無し
合計 26.5万円~51.5万円 約4万円~

ソフトウェアの保守費用は、ソフトウェアランニング費用、機能追加費用、バグ修正で分けて考えてみました。

ライセンス費用は、スクラッチであればソフトウェア保守費用として開発会社と月次の支払いを契約することが一般的で、開発されたソフトウェアの規模によって費用がかわります。ここでは開発費を1,500~3,000万円、保守費用を開発費の10~15%と想定しています。

保守契約は、契約の内容によって対応できる工数に上限が決められているケースもあり、全ての要求に対応してくれるものではありません。一方で、契約次第にはなりますが、保守で決められた工数に収まるのであれば、新規の機能開発に応じることが可能な場合もあります。

パッケージソフトの場合は、ソフトウェアライセンス費用がこれに該当します。年間や月額等ソフトウェアによって契約期間が違います。

機能追加については、スクラッチの場合、開発ベンダーに追加費用を支払うことで比較的自由に機能開発できるメリットがあります。パッケージソフトの場合、新規に追加される機能はソフトウェアベンダーの対応や開発スコープに依存するため、要望がすべて反映されるとは限りません。一方、パッケージソフトはエディションによって機能・価格が分かれているものもあり、ライセンス費用をあげるだけで、開発に必要なリードタイムをかけずに、より多くの機能を利用できるといったメリットがあります。

スクラッチでは費用負担することで機能追加ができるものの、ソフトウェアの機能や仕様が複雑・巨大化するにしたがって、ソフトウェアランニング費用として保守契約の見直しが発生することもあります。

比較結果

コストを比較すると、インシデント管理ツールはパッケージソフトウェアを利用した方がお得になるポイントが理解できたかと思います。

  • ソフトウェアの専任技術者の有無
    スクラッチは専任が望ましく、パッケージは慣れてくれば兼任でも可能。
  • ソフトウェアランニング費用
    スクラッチは開発会社との保守契約で開発規模が勘案され、パッケージは年間又は月額のライセンス費用。
  • 機能追加の費用
    スクラッチは費用があれば追加自由度が高く保守費に影響がでる場合があり、パッケージはエディション等機能差異の違いで強化可能。
  • バグ修正費用
    スクラッチは保守費で対応できることもあるが特別対応の場合は別途費用負担あり、パッケージはライセンス費用以上の負担は発生しない。

パッケージソフトウェアにはソフトウェア費用とは別に、サポートのサービスが付帯されている場合もあります。ソフトウェアの利用に慣れていない導入初期などには重宝すると思います。

まとめ

今回はパッケージソフトウェアとスクラッチソフトウェアのコスト差についてご説明しました。すでにスクラッチソフトウェアを利用している場合、パッケージソフトウェアに切り替えることで、どの部分でコストの違いが出てきそうか理解してもらえたでしょうか。

【ROI算出シートセット】「ツール導入でコスト50%削減」を実現しよう!ServiceDesk Plus活用による4つの改善事例

改善事例のダウンロード

その他の記事:インシデント管理ツールの導入とコスト・費用対効果について


フィードバックフォーム

当サイトで検証してほしいこと、記事にしてほしい題材などありましたら、以下のフィードバックフォームよりお気軽にお知らせください。

Comments are closed.